Day08 - 一起來看 Kubernetes 官方文件吧！- 使用 kubeadm 安裝 HA-cluster (上)

16th鐵人賽 kubernetes

a259108736

2024-09-22 22:03:56

146 瀏覽

分享至

前言

前篇透過 kubeadm 建立了 “還不能用的” 單節點 cluster，讓我們繼續來看看在使用 kubeadm 時還需要哪些東西才可以完成 HA cluster

今日目標

了解 kubeadm 的 etcd Topology 差異
了解如何準備 loadbalancer

etcd Topology

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

前面有討論到 kubeadm 指令可以僅安裝 etcd（不過也是透過 kubelet 的方式帶起 container 來用)
而其實在這篇文章中，也僅有分成兩種：etcd 放在外部或內部

Stacked etcd topology (內部)

此為 kubeadm 預設建立的架構，當使用 kubeadm init and kubeadm join --control-plane 兩種指令時。
從圖中可見，etcd 被放在每一台 control plane 上，也就是同一台機器上，並且前方透過 load balancer 導送流量至 apiserver
圖中還有另一個重點，即是每台 apiserver 是直接對上本機上面的 etcd (若沒特別配置的話就是指定 127.0.0.1:2379)

優點：

可以準備較少機器
配置較為簡單

缺點：

相較於外部 etcd 的部署方式耦合度較高，可能會因為元件間故障互相影響

**External etcd topology (外部

etcd-topology**

把 etcd 部署在額外的主機上面，其餘相同。

優點：

降低各元件影響到 etcd 的可能性
提高可用度

缺點：

需要建立額外的主機
更新流程需要獨立出來，無法與 control plane 一同升級

筆者沒有嘗試過這樣的做法，不過上圖在 apiserver 至 etcd cluster 這邊沒有特別標示是連線到哪一台，推測下方也會需要一個 load balancer 來做到 etcd 流量的轉發。
參考：https://github.com/n8sOrganization/etcd_load_balanced/blob/main/README.md

實際上兩者的差異

在討論 k8s 的可用性時，實際上 apiserver 只需要確保有一台活著 + Loadbalancer 轉送流量即可提供服務。
但 etcd 則是採用 Raft 演算法，節點可用數為 n/2 -1 ，也就是當有 3 台節點時可容忍 1 台損毀，5 台時則是 2 台，詳情可見以下表格

因此把 etcd 獨立到另外的機器上，是可以一定程度增加 k8s 上的可用性的。

官方建議的 loadbalancer 準備方式

https://github.com/kubernetes/kubeadm/blob/main/docs/ha-considerations.md#options-for-software-load-balancing

以上是 kubeadm 的 github 文章，提供了很詳細的 Loadbalncer 選項，主要有兩種實作方式：

haproxy + keepalived：老牌組合，算是比較穩定的方式。keepalived 提供 Virtual IP，haproxy 提供 load balancing。
kube-vip：透過一個服務完成 VIP + load balancing。可透過 layer2 (ARP) 或 Layer3 (BGP) 來實作

詳細內容就先略過了，有興趣的讀者可以看看上方詳細的文件

kube-vip

透過文件內的指示，以下指令即可產生 kube-vip 的 static pods manifest 提供給 apiserver

#!/bin/bash

export KVVERSION=$(curl -sL https://api.github.com/repos/kube-vip/kube-vip/releases | jq -r ".[0].name")
# 設定同 CIDR 的 IP
export VIP=192.168.75.10
# 指定 interface
export INTERFACE=ens33
# 透過 kube-vip 的 container 產生配置檔案
sudo ctr i pull  ghcr.io/kube-vip/kube-vip:$KVVERSION
sudo ctr run --rm --net-host ghcr.io/kube-vip/kube-vip:$KVVERSION vip /kube-vip manifest pod \
    --interface $INTERFACE \
    --vip $VIP \
    --controlplane \
    --arp \
    --leaderElection | sudo tee /etc/kubernetes/manifests/kube-vip.yaml
# k8s 1.29 之後的問題，暫時排解方式
# 只須在第一台 control-plane node 執行
sudo sed -i 's#path: /etc/kubernetes/admin.conf#path: /etc/kubernetes/super-admin.conf#' \
          /etc/kubernetes/manifests/kube-vip.yaml

在上次建立的 k8s cluster 中，即可看到 kube-vip 以 static pods 的形式被帶起來提供服務：

sudo crictl ps | grep kube-vip
30c4002d273cb       e3e941ba21d00       4 minutes ago       Running             kube-vip                  0                   7819f5cf3a4fa       kube-vip-k8s-master1

如此提供給 apiserver 的 loadbalancer 就準備好了
kube-vip 會使用 192.168.75.10 這個 IP 轉發流量至各台 control-plane 的 apiserver 上，